Toward the Rigorous Use of Diagrams inReasoning about

We propose that the concept of \formal methods" be expansive enough to include a rigorous, integrated use of diagrams for automated reasoning tasks. Applications to hardware design provide an especially rich domain to explore visually oriented extensions of traditional logic. This domain has an established methodology embracing the use of diagrams; it promises to light the way toward modernizing the foundations of formal logic. In this paper we examine some of the issues exposed when one attempts to develop a rigorous basis for heterogeneous and visually oriented reasoning. . Toward the Rigorous Use of Diagrams in Reasoning about Hardware Steven D. Johnson , Jon Barwise, and Gerard T. Allwein. Johnson's research supported, in part, by the National Science Foundation under grants numbered MIP89-21842 and MIP92-08745. 2 Author's name Introduction The logician's conventional notion of proof has grown increasingly anachronistic through the twentieth century as computing capabilities have advanced. Classical proof theory provides a partial model of actual mathematical reasoning. When we move away from mathematics toward reasoning in engineering and computation, its limitations are even more pronounced. The standard idea of a formal system seems frozen in the information technology of Frege's time; it is decidedly quaint in the presence of today's desk-top computer. Contrary to formalists' dogma, experience suggests that pictures, graphs, charts, and diagrams are important tools in human reasoning, not mere illustrations as traditional logic would have us believe. Nor is the computer merely an optimized Turing machine. The computer's graphical capabilities have advanced to the point that diagrams can be manipulated in sophisticated ways, and it is time to exploit this capability in the analysis of reasoning, and in the design of new reasoning aids. In this paper we propose a new understanding of the role of various sorts of diagrams in the speci cation and design of computational hardware. This proposal stems from a larger project, initiated by Barwise and Etchemendy [3], the goals of which are to develop a mathematical basis from which to understand the substantive logical relationships between diagrams and sentences, and to develop a new generation of automated reasoning tools from that basis. Microelectronic CAD systems are among the supreme examples of visualized reasoning environments. Their tools are highly oriented toward diagrams, are quite sophisticated, and are comparatively well integrated. These systems also integrate logical and physical design, providing a strong coherence between speci cation and implementation views. Formalized reasoning meshes poorly with these working frameworks. Although it provides needed rigor for today's highly complex design challenges, its preoccupation with formulas at the expense of diagrams is simply too cumbersome. We should attempt to draw lessions from these advanced design environments, making the reasoning rigorous without subverting their character. This paper is built around two simple design examples: a synchronizing circuit and the \Mead-Conway" tra c-light controller. Our purposes are, rst, to illustrate heterogeneous use of pictoral \formalisms" in design, and Title 3 second, to expose basic questions for the logical analysis that follows. Between the examples, we will develop a common mathematical basis in which the examples can be analyzed. These are admittedly modest beginnings, but we hope that they start to put to rest the idea that only formulas can be used in formal reasoning. 4 Author's name The CircuitProof project The foundations of the research described here arose from previous work in information theoretic aspects of logic: Turing's World, a program for building and running Turing machines using only graphical representations for them [2], and Tarski's World, a program to teach the language of rst-order logic [4]. The success of these programs shows the power of graphical designs in reasoning in logic, but it also raises a host of new theoretical issues and possibilities. Exploring these has led to the development of Hyperproof, 1 a specialized heterogeneous reasoning system developed under the guidance of Barwise and Etchemendy by Allwein, Greaves, and Lenz [1, 5]. This program is now being used at Stanford, Notre Dame, and Indiana to teach basic reasoning skills to students in a way that makes crucial use of visualization of information. Hyperproof is a formalism for use in reasoning about blocks worlds by using a combination of diagrams and sentences of rst-order logic. Figure shows a Hyperproof session. In it, partial knowledge is used to discover facts about a situation. There is signi cant interplay between the information system represented by the picture and the proof manager. For instance, information in the picture is used to determine whether case analyses are exhastive; in fact, cases themselvesmay be represented by hypothetical board con gurations. Hyperproof is very specialized and could not be applied to hardware description. However, there are some important lessons to be learned from Hyperproof, lessons which have informed the project initiated here, and which we summarize very brie y now. The rst lesson|which is hardly new but seems to be ignored in the standard logical formalisms|is that nding the best representation of a problem is often the most important step in solving the problem. The reason engineers use various sorts of diagrams is because they are highly e cacious representational schemes. The second lesson learned from Hyperproof is to explore \heterogeneous" systems, systems in which two or more di erent types of representation are used side by side. Typically di erent formalisms will be better for talking about di erent aspects of the problem or device under con1Hyperproof is a joint project of the Visual Inference Lab at Indiana University and CSLI at Stanford University. Title 5 Figure 1: A Hyperproof display 6 Author's name sideration. As long as there is a common subject matter, this subject matter will tie the various formalisms together, giving us a notion of valid inference. Finally, Hyperproof shows that we need a \hyperstructure," the place were proofs are given using a mixture of the various formalisms. CircuitProof is a pilot study with three goals. The rst is to examine engineering practice in order to develop a suite of integrated reasoning tools, some based on sentences and some based on diagrams, which are useful in circuit-design applications. In this paper we will con gure such a suite containing nite state diagrams, circuit schematics, timing diagrams, as well as second order logic. The second goal is to engage research in the formalmethods area, where there is an abundance of visually oriented design tools for logicians to study. Finally, we want to inform the engineering community that automated reasoning of the kind that is entailed in hardware design is not necessarily textual. Logicians bear as much responsibility as tool developers to bridge the gap between practice and formalism. Title 7 Diagrams and hardware description It is hard to write, talk, or think about circuitry without using diagrams. Virtually all articles about formalizing hardware description make heavy, though usually intuitive, use of schematics, physical drawings, timing diagrams, state machines, and so on. It is so common that we may regard it as vital. Structural qualities of the circuits may justify the use of diagrams, but the correlation between a physical circuit and its schematic is di cult to pin down. Often, these di er dramatically. There must be other reasons for the ubiquitous use of diagrams. As in many realms of mathematical discourse, the interaction of a narrative argument and a circuit diagram yields an e cient mode of explanation. The following excerpt from [7] is typical: \: : : When A = B either the N-types will be turned on or the P-types. They will clamp the input to the strong (S) inverter, overpower the weak (W) inverter, and the output will change to the proper level. When A and B are di erent neither a pull-down or a pull-up path will exist and the previous output will be maintained by the latch formed by the W and and S inverters. : : : W S Vdd A B C A conventional formalization of this argument represents the diagram as a sentence. In predicate logic for example, one would employ relations for devices, variables for wires, and conjunction for composition [8]. The narrative sketches a proof, \this circuit is a C-element," listing relevant facts that can be extraced from such a formula and which, taken together, should imply the behavioral properties of a C-element. This regimen for veri cation raises several questions, but foremost is its denial at the outset that the diagram itself is serving any purpose. We can see that it serves at least as a referent to the narrative. Once everything is distilled to sentences it is hard to see how 8 Author's name to recover this manner of reference. Discovered properties like \pull-down path" and \latch" emerge as syntactic qualities of the diagram, but would otherwise have to be indirectly developed in the course of a formal deduction. Hunt o ers a radical statement of purist objectives [12]: \We envision providing a mathematical statement which we call a formula manual [Hunt's italics], that completely speci es the operation of a hardware component. With respect to digital systems, we want to: [1] Completely replace programmer's manuals, timing diagrams, interface speci cations, power requirements, tec. with clear precise formulas. [2] Provide a perfectly clear foundation upon which systems can be built." Surely this is not the world to which we really aspire, for while the programmer's manual may convey information imperfectly, it conveys that imperfect information rather e ciently in human terms. Hunt is justi ably calling for greater rigor in the description of hardware, but his formula manual, as described, would be of marginal bene t to the human user. Cohn poses the central problem in her summary of the VIPER veri cation project [6]: \The rst task in the [block level] veri cation e ort is to derive a functional expression of the block model in a formal logic which is suitable for reasoning and proof. This is necessary because it is di cult to reason formally about a schematic diagram indicating [information ow]. It is possible to imagine doing this by reasoning about sequences of annotated pictures, but the real problem is not so much the obvious awkwardness of such a method as the lack of a formal semantics of pictures. : : :" A reasoning system based purely on pictures would, of course, be awkward, but on the other hand, so is purely textual reasoning, judging from the experience gained to date. Given the human tendencies for using both forms, it is worth investigating a middle ground. A notable example of work connecting diagramatic representation with formal proof is the LAMBDA system of Fourman and others [9]. A schematicentry facility called DIALOG associates graphical symbols with HOL proof Title 9 tactics, which are invoked as new components are connected. These tactics generate proof obligations, which may be resolved by either graphical or textual interactions with the system. We think the claim that such tools make \[formal methods] accessible to design engineers" is a valid one. For this reason, serious attention should be paid by logicians|and the implementers of automated reasoning systems|to what have heretofore been regarded as mere human-interface issues. In the remainder of this paper we examine some of the questions that arise when diagrams are used in hardware design. We cannot o er comprehensive answers to any of these questions, nor yet a system to implement these paradigms. However, we strongly believe that the formal-methods community should engage itself with questions of this nature, in order to help establish a new foundation for 21st century logic. 10 Author's name The Unit-Pulser Example To illustrate a perspective on design, let us consider a simple example, drawn from the textbook by Winkel and Prosser [14]. We will present the example as it might be developed in an actual design class, with all the diagrams one would naturally use. Our claim is relatively simple: properly understood, this design process is a logically rigorous piece of reasoning it as it stands. There is no need to (and every reason not to) reduce the diagrams used in the reasoning into some more standard formal system. In this paper, we assume a globally clocked, synchronous design technology.Suppose one wants to design a device with a single one-bit input and a single one-bit output: SP i o SP's external behavior is stated informally as follows: \SP emits a unit-pulse on o for each pulse received on i." This speci cation, of course, leaves many things open, things which would have to be settled in the design of an actual device. The timing diagram given below provides a somewhat more exacting speci cation of SP's behavior by requiring that the output pulse occur in the neighborhood of its corresponding input pulse. i o This speci cation is still fairly open to interpretation. Any simple implementation in hardware would determine where in the interval to generate the output pulse. Let us think of this timing diagram as a \requirements speci cation." The Title 11 state-machine diagram below can be thought of as a design speci cation: S0 S1 0/0 1/0 1/0 0/1 Using a standad interpretation as an !-automaton of some kind a device is described with two states and a speci c input/output behavior in each of these states. Our rst observation is that any device described by this Mealy machine diagram has an input-out behavior that satis es the requirement speci cation. Indeed, we can say more, since it will have a behavior that is described by the following timing diagram. i o ? At a purely logical level, this can be made perfectly rigorous, every bit as rigorous as the fact that A(f(3)) follows from 8xA(x), as we will show. This diagram re ects an undetermined choice of the starting state for the machine: we cannot know whether a pulse is issued at \time zero." But given the condition that input i is initially zero, the machine settles into a desirable behavior, generating its output pulse at the end of the input pulse. Whether this output pulse lies within the \neighborhood" speci ed by our earlier timing diagram can only be settled by giving a rigorous semantics; including a precise meaning to the \ellipsis" symbols in the waveforms. So much for the purely logical aspects of this step of the exercise. Let us look ahead to a future where there is computational support for such reasoning. Perhaps we can build a simulator/veri er to certify the following 12 Author's name relationship: S0 S1 0/0 1/0 1/0 0/1 i ? o This is plausible given recent developments in symbolic simulation and inductive theorem proving. It should be at least as practical as automated proofs by induction, since there is a very simple instance of induction to verify that a simulation relationship holds. Moving on in the design process, let us construct a circuit to implement the state machine. The circuit diagram below is obtained by a (well-known, but see Appendix A) general construction based on a \one-hot" representation of control. Brie y, in a one-hot controller there is one dip op for each state of the machine.